IBIS Macromodel Task Group

Meeting date: 12 January 2016

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI):                  Xingdong Dai
                              Bob Miller
Cadence Design Systems:       Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
Cisco:                        Seungyong (Brian) Baek
eASIC:                        David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
GlobalFoundries:              Steve Parker
Intel:                        Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:              John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.:                 James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys:                     Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong


The meeting was led by Arpad Muranyi.

--------------------------------------------------------------------------------
Opens:

- There will be no ATM meeting on January 19th (next week) because of DesignCon
  and the associated IBIS summit.

- Arpad noted that the following changes he had made to the ATM agenda's Pending
  BIRDs section:
  - BIRD179 "New IBIS-AMI Reserved Parameter Special_Param_Names" was removed
    from the list because it was Accepted by the Open Forum during the December
    18, 2015 meeting.
  - A TBD entry was added for the "C_comp modeling with IBIS-ISS" topic that had
    been introduced by Randy Wolff and discussed in previous ATM meetings.
    
- Arpad noted that Bob Ross had prepared a presentation on Voltage References in
  IBIS and asked to review it at today's meeting.
  

--------------------------
Call for patent disclosure:

- None.

-------------
Review of ARs:

- None.

-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Radek: Motion to approve the minutes.
- Arpad: Second.
- Arpad: Anyone opposed?  [none]

-------------
New Discussion:

New Redriver Flow BIRD:
- Discussion: Arpad asked Fangyi if he had any updates on this topic.  Fangyi
  said that he is working on a solution and preparing slides.  He will
  distribute them when they are ready.
  
Fixing [Pin Mapping]:
- Walter: [sharing the presentation he plans to deliver at the DesignCon IBIS
           summit next Friday].
- Discussion: Walter's presentation highlighted a particular sentence in the
  [Pin] section of the spec:
     "The second column, signal_name, gives the data book name for the signal
      on that pin."
  Walter said this statement should have ramifications in terms of the way we
  allow IBIS [Component]s to connect things via the [Pin] section and the bus
  labels in [Pin Mapping].  The bus labels defined in the [Pin Mapping] section
  are generally identical to the signal_names from the [Pin] section.  The spec
  does not require this, arbitrary bus label names can be created and used.
  However, this sort of indirection in the bus label names can lead to non-
  sensical connections that neither the spec nor the parser explicitly disallow.
  His presentation includes nonsensical cases in which an arbitrary bus label
  name is used to short [Pin]s with model names POWER and GND.  He also pointed
  out an example in which the [Pin] section used the same signal_name for one
  POWER Pin and one GND Pin.  He noted that it was self-evident that this should
  be a spec violation, given the signal_names = data book names statement.
  However neither the current spec nor the current parser explicitly prevented
  such nonsensical connections.  Walter proposed two new rules to formally
  codify the intent of the spec:
    1.  All [Pin]s with the same signal_name must use the same [Model] name.
    2.  All POWER/GND [Pin]s connected to the same bus label must have the same
        signal_name.
  Walter stated that every IBIS [Component] he had ever seen with a [Pin
  Mapping] section had used bus label names identical to the signal_names.  He
  felt that introducing these rules would not in practice break our rules about
  backward compatibility.  He felt that it was likely a bug in the initial spec
  that these types of nonsense connections weren't already explicitly illegal.
  Walter also introduced the concept of a "Signal_names_are_bus_labels" option
  to explicitly state the case and also allow simplifications in the [Pin
  Mapping] section, such as not needing to include the POWER and GND [Pin]s in
  the [Pin Mapping] section.  This might even be considered the default
  assumption (no need for the new option).  Bus label names could still be used
  to further subdivide groups of [Pin]s that had the same signal_name (in this
  case it would be necessary to introduce bus label names different from the
  signal_name itself).
  Bob expressed general support for this enhancement, though he thought there
  might be a detail or two to be worked out with respect some of the
  interconnect discussions.  Arpad objected to a statement on the final summary
  slide that these new rules were required to make [Pin Mapping] "useable."
  He stated that just because the model maker could do silly things didn't make
  [Pin Mapping] unusable, and used the analogy of mistakenly using a .connect
  statement in SPICE to connect different voltage rails (Bob agreed).  He said
  that we usually wanted the parser to focus strictly on syntax, not enforcing
  reasonable models.  Radek pointed out that that we have the parser check
  rules from the spec, and we could introduce new explicit rules.
  Additional open questions left from the discussion:
  1.  Radek asked if Walter also intended to clarify that only POWER [Pin]
      connected bus labels could be used in the pu_ref column, and only GND
      [Pin] connected bus labels could be used in the pd_ref column.  That
      is, only a POWER [Pin] could be the pu_ref for an I/O Pin and only a
      GND [Pin] could be the pd_ref.  Walter said that this was another
      decision that we could make, but that the example for bug 172 had
      provided a case in which one I/O Pin used VSS as its pu_ref and VDD
      as its pd_ref.  It was an open question if we wanted to decide not to
      allow that.
  2.  In reviewing ibischk BUG 172 with Curtis and Bob, Radek had noticed an
      additional issue with the parser.  The spec says that a POWER [Pin]'s
      entry in the [Pin Mapping] section should have its bus label specified
      in the pu_ref column.  Similarly, a GND [Pin]'s entry should have its bus
      label specified in the pd_ref column.  However, the current parser only
      issues a warning (not an error) if this rule is violated and a bus label
      is specified in one of the other columns.  Should we have the parser
      report an error in this case?  This may be part of the BUG 172 discussion.

Discussion of Voltage References in IBIS:
- Bob: [Sharing his presentation on the history of voltage references in IBIS.
        Presentation is now available in the ATM work archive.
        http://ibis.org/macromodel_wip/archive-date.html]
- Discussion: Bob reviewed his presentation.  He stated that IBIS was full of
  implicit references to "node 0" [referred to as 0.0V in his presentation]. The
  presentation covered a long list of IBIS keywords, terminal names, etc.  Bob
  stated that for a variety of historical reasons and syntactical reasons (e.g.,
  no separate reference node provided anywhere in the syntax) node 0 was an
  implicit reference for all of them.  Ultimately, Bob suggested that fixing
  this would require an intensive page-by-page scrub of the spec to see exactly
  what had been intended in each case and how it could be resolved.  Walter
  objected to Bob's interpretation.  He said that the implicit references to
  zero arose out of the discussions of test fixturing for the measurement of
  I/V and v(t) curves.  The test fixture assumes the pd_ref is tied to "0",
  but at simulation time things would be calculated with respect to the floating
  pd_ref node.  Arpad also disagreed, and said that his recollection of
  [Voltage Range], for example, was that it was the voltage between the pu_ref
  and pd_ref terminals for the device, not between the pu_ref and absolute
  ground.  Radek mentioned one example, A_gnd, and said he thought it was
  probably a mistake to have the expression "similar to SPICE ideal node '0'"
  in its description in the spec.  He said it was actually a local ground
  reference that needed to be defined.  He said it was important that all
  these implicit references be clarified.  Everyone agreed that Bob's
  presentation provided good historical context for the discussion.

- Arpad: Thank you all for joining.
-------------
Next meeting: 26 January 2016 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
